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Abstract 
The Ph Nameserver from the Computing and Communications Services 
Office (CCSO), University of Illinois at Urbana-Champaign has for 
some time now been used by several organizations as their choice of 


publicly available database for information about people as well as 
other things. This document provides a formal definition of the 


client-server protocol. The Ph service as specified in this document 


is built around an information model, a client command language and 
the server responses. 


1. Overview 
1.1. Basic Information Model 


At its simplest the Ph database can be thought of as a computer- 
resident "phone book". However, it can be used to collect arbitrary 
information about people, and in response to a query about an object 
named in the database, return information about that entity. It is 
in short a nameserver for people and objects. It was designed to 
keep a relatively small amount of arbitrary information about a 
relatively large number of people or things, and provide access to 
that information over the Internet. In order to structure the 
information the manager of the database has to decide which views to 
present of the real-world objects that are to be represented in the 


database. Each view is then composed of a number of fields and their 


values. To support this concept Ph has the notion of named 
information, i.e., categorizing information into what are called 
fields and assigning descriptive names to those fields. 
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Even if the database resides and is reachable from the Internet it is 
local in the meaning that no server is supposed to be able to refer a 
client to another server which might hold the wanted information. 
However a server may contain a list of other Nameservers which can be 
used by clients to query other Nameservers for information. 


1.1.1. Fields 


A field descriptor is associated with each field and is used to 
describe the type and behavior of the field. A field descriptor 
includes the fieldname, the maximum length of information the field 
can store before truncation, keywords describing the properties of 
the field as well as free text describing what kind of information 
the field is supposed to hold. 


The keywords can be any of the following: 


Always: 


Any: 


Change: 


Default: 


Encrypt: 


ForcePub: 


Indexed: 


LocalPub: 


Lookup: 


NoMeta: 


Forces the field’s contents to be always printed in 
addition to whatever fields specified by the query. 


This field is always searched by queries. To be most 
use ful, a field marked as Any should also have the Indexed 
and Lookup keywords as well. 


Can be changed by the owner of the entry. 
Printed if no return clause is given in the query. 
Must be encrypted before transmission. 


Viewable/searchable regardless of the content of the 
suppress field 


Fields that are kept track of in the database’s index for 
efficient lookups. At least one indexed field must be 
present in each query. 


May be viewed by anyone in the "local" domain or address 
space. Fields with this keyword are completely invisible 
outside of the "local" domain. They will not be shown with 
the fields command (section 3.3), and are disallowed in 
query commands or return clauses (section 3.8). 


May be used in the selection part of a query. A Field 
without this keyword may not be used to select entries. 


Wildcard searches are disallowed. 
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NoPeople: No entry of type "person" may include this field. 
Private: Field may be viewed by Heros (section 1.4) only. 


Public: May be viewed by anyone. Fields not marked with this 
keyword may only be viewed by the entry’s owner or a Hero. 


Sacred: Changes to the field are prohibited except via non-network 
invocations of the server, i.e., from a tty, file, or pipe. 


Turn: Users may turn off visibility of a field to everyone except 
themselves and Heros by prefixing the field text with ’*’. 


Unique: Any change to the field will be rejected if the change 
causes the modified field to match the same field in any 
other entry. 


1.1.2. Character Sets 


Historically Ph has been restricted to only handle printable 
characters, that is characters with hexadecimal values between 0x20 
and Ox7f. Lately with the spreading of 8-bit clean Operating Systems 
there is no reason to keep this limitation. 


This document therefore proposes that ISO-8859-1 shall be regarded as 
an alternative character set for Ph, the default still being US- 
ASCII. 


Clients that utilize ISO-8859-1 should request that the server return 
TSO-8859-1 by using the "set"-command. 


In the instance that values are stored using ISO-8859-1 and are to be 
shown to a client expecting US-ASCII, the characters with character 
codes outside of the US-ASCII range should be displayed in the 
"Quoted-Printable" content-transfer-encoding form defined in RFC-2045 
[MIME]. 


1.2. Standardization issues 


Each Nameserver manager is in essence free to name new fields to suit 
the special needs of his/her organization. But in order to make the 
directory service useful outside of the organization it is 
recommended that a core set of standard fields always should be 
present. 


Therefore this document defines a couple of standard collections of 
fields (Appendix A). 
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Also note that the architecture makes no assumption about the search 
and retrieval mechanisms used within individual servers. Operators 
are thereby free to use any kind of dedicated databases, fast 
indexing software or even gateways to other directory services to 
store and retrieve the information, if desired. 


Ph simply functions as a known front-end, offering a simple data 
model in addition to a well known port and simple query language. 


1.3. Conventions Used in this Document 


In examples, "C:" and "S:" indicate lines sent by the client and 
server respectively. 


1.4. Heros 


For Ph a Hero is equivalent to a superuser or operator. Being in 
Hero mode means that some or all artificial limits are removed; full 
Heros may change any field in any entry in the database, as well as 
view as many entries as they wish. Heros can also be limited to one 
field of one other entry. Hero mode is used mostly for 
administrative purposes, delegation of group authority over selected 
fields, and is controlled by the acl field. 


2. Basic Operation 


Initially, the server host starts the Ph service by listening on TCP 
port 105. When a client host wishes to make use of the service, it 

establishes a TCP connection to the server host. The client and the 
Ph server then exchange commands and responses (respectively) until 

the connection is closed or aborted. 


2.1. Command syntax 
Commands in Ph consist of a keyword optionally followed by zero or 
more keywords or values, separated by spaces, tabs or newlines, and 
followed by a carriage return-linefeed (CRLF) pair. A more thorough 


description using BNF is given in Appendix C. 


Values containing spaces, tabs or newlines must be enclosed in double 


quotes (’""’). In addition the sequences "\n", "\t","\"" and "\\" may 
be used to mean newline, tab, double quote and backslash, 
respectively. 


Keywords must be given in lower case; case in the values of fields is 
preserved, although queries are not case-sensitive. 
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2.2. Response syntax 


Responses consist of a result code followed by additional information 
possibly separated by entry index and/or field name and are 
terminated by a CRLF pair. 


result code: [entry index:] [field name:]text 


Responses to some commands might be multi-lined. In these cases each 
line in the response, except the last, has the appropriate result 
code negated (prefaced with "-"). The last line then starts with the 
appropriate result code without negation. Each line must be 
terminated by a CRLF pair. 


If a particular command can apply to more than one entry, then the 
multilined response must be so organized that all information 
pertaining to each entry is returned on consecutive lines, and that 
each of those lines must have one and the same entry index directly 
following the resultcode. The first entry index should be 1 and 
incremented each time a new entry is referred to. 


C: query hedberg return email name title 

S: 102:There were 3 matches to your request. 

So =20081: email: canheg95@student.umu.se 
S: -200:1 name: Carl Johan Hedberg 

S: -200:1 title: Student 

S: -200:2 email: parheg95@student.umu.se 
Si E2002 name: Par Hedberg 

S200 2% title: Student 

Se =20033% email: Roland.Hedberg@umdac.umu.se 
S3 =20083 name: Roland Hedberg 

Ss =200:3 title: Boss of the Network group 
S: 200:0k 


Commands that can apply to more than one field must have the name of 
the field to which the response applies directly following the entry 
index. 


The text of the response will be either an error message in human 
readable format, or data from the Nameserver. Whitespace (spaces or 
tabs) may appear anywhere in the response, but the field name and 
text columns if present must each begin with a whitespace character. 


Since more than one specific piece of information may be manipulated 
by a particular command, it is possible for parts of a command to 
succeed, while other parts of the same command fail. This situation 
is handled as a single multi-line response with the result code 
changing as appropriate. 
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As for FTP, the result codes are in the range 100-699 (or from -699 
to -100 for multiline responses), where the leading digit has the 
following significance: 


In progress 

Success 

More information needed 

Temporary failure; it may be worthwhile to try again. 
Permanent failure 

Phquery specific codes 


NU PWN E 


Many commands generate more than one line of response; every client 
should be prepared to deal with such continued responses. Note that 
a command is finished when and only when the result code ona 
response line (treated as a signed integer) is greater than or equal 
to 200. 


Clients should assume that any numeric response, within the above 
mentioned ranges, are valid. Also note that the server is allowed to 
send one or more lines with result codes between -199 - -100 (the 
leading "-" indicates a continuation line) and 100 - 199, as status 
information, before the actual results are transmitted. 


2.3. Format of a search string 


Matching is not sensitive to upper or lower case letters and is 
normally done on a word-by-word basis. That is, both the query 
expression and the entry information is broken up into words, and 
individual words are compared using exact matching. If the order of 
the words is important in a query, then the query string can be 
surrounded by ’"’ (double quotes), whereby the complete search string 
is matched against the information in the Nameserver database. 


Word delimiters are the following characters: <SPACE>, <TAB>, <NEW- 
LINE>, ",", ";" and ":" . These characters are not indexed and 
should not be part of the search string. 


However, special symbols, called "wildcard" characters, can be used 
if the exact spelling is unknown. The ’*’ (asterisk, 0x2A) is used 
in place of zero or more characters, ’+’ (plus, 0x2B) in place of one 
or more unknown characters, and ’?’ (question mark, 0x3F) can be used 
when exactly one character is unknown. If the unknown character can 
be one of a limited set this can be specified by surrounding the set 
with brackets, e.g., [ei] means that in that place an ’e’ or an ’i’ 
would match. 
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3. Commands 


3.1. status 


status 


Prints the 
nameserver 


stat 
100 
100 
100: 
100 
200 


NNNNNA 


3.2. siteinf 


siteinfo 


Returns in 


Version 
Maildomain 
Mailfield 
Mailbox 


Administra 
Passwords 
Authentica 
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message of the day and the current status of the 


us 


:Qi server $Revision: 1.6 $ 
:Ph passwords may be obtained at CCSO Accounting, 


1420 Digital Computer Lab, between 8:30 and 5 Monday-Friday. 


:Be sure to bring your U of I ID card. 
:Database ready 


(0) 


formation about the servers site. Possible fields are 


Version information for the server. 
The mail domain to use for phquery-type mail. 
The field containing the specific email address. 
Mandatory entry that names the field to use as 
maildrop. 
tor Guru in charge of service. 
Person in charge of ordinary password/change requests. 
te Authentication methods supported by the server, 
ordered in the site-preferred way. Presently the 
following options are defined: 


1 attempt auto login 

2 allowed to be interactive if needed 
4 use ANSI X9.9 challenge/response 

8 use v4 Kerberos login 


16 use v5 Kerberos [KRB5] login 

32 use GSS-API [GSS-API] login 

64 use email login 

128 password encrypted response to challenge 

256 use clear-text password 

512 use HMAC [HMAC] with SHA-1 of challenge string 
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Example 
C: siteinfo 
S: -200:l:version:3.1 
S: -200:2:maildomain:umu.se 
S: -200:3:mailfield:alias 
S: -200:4:mailbox:email 
S: -200:5:administrator:roland.hedberg@umdac.umu.se 
S: -200:6:passwords:roland.hedberg@umdac.umu.se 
S: -200:7:authenticate:64:32:128 
S: 200: Ok. 


The mail fields in the siteinfo command direct how address 
information stored in the Nameserver is to be used for delivering 
mail. 


The specific (username, host) pair to where a user’s mail should be 
sent for final delivery is stored in the field named by {mailbox}. 
Phquery and like utilities will use this field. 


To construct a useable email address from Nameserver information, the 
algorithm below is followed: 


if ({maildomain} is not null) then 

address = (contents of {mailfield}) @{maildomain} 
else 

address = (contents of {mailfield}) 


Some existing client software will not format email addresses 
correctly if the value of {mailbox} is set to anything other than 
"email" when {maildomain} is non-empty. 


If {mailbox} is set to anything other than {email}, {maildomain} must 
be reported empty by the siteinfo command. Also reformatting of each 
record’s {mailfield} must be done by the server before reporting it 
to the client. 


3.3. fields 
fields [field ...] 
Without an argument, a list of all available field descriptors should 
be delivered. Any space-separated argument(s) restricts the list to 


the named fields. Fields marked with the "LocalPub" keyword (section 
1.1.1) should not be delivered outside of the local domain. 
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The output of the command consists of two lines describing each 
field. The first line defines the field in technical terms (max 
length and field attributes), while the second line is a brief 
description of what the field is intended to hold. The second 
number of each response is the field id number. 


fields 
-200: 
-200: 


C 
S :alias:max 32 Indexed Lookup Public Default 
S :alias:Unique name for user. 

S: -200:3:name:max 64 Indexed Lookup Public Default 
S: -200:3:name:Fullname 

S: -200:2:email:max 128 Lookup Public Default 

Ss 

S 

S 

S 

S 

S 


NWWOAOAO 


-200:2:email:Account to receive electronic mail. 
-200:16:other:max 256 Lookup Public Default Change 
-200:16:other:Other info the user finds important. 
-200:33:home_phone:max 60 Lookup Public Change Turn 
-200:33:home_phone:Home telephone number. 

200:0k. 


3.4. id 
id information 
Enters the given information in the Nameserver’s log. This command 
is used by the Ph client to enter the user id of the person running 
iG: 

3.5. set 
set [option[=value] ...] 
Sets the named option for this nameserver session to a value. The 
default string "on" is used if no value is supplied. Used without 


arguments it return the settable options and their current value. 
Some common options are 


echo If on, echo the client’s commands back to the client. 

limit Changes that affect more than the specified number of 
entries results in an error. 

charset Return responses to the client in the character set 
specified. 

verbose If on, report interim progress messages to the client. 

addonly If on, change commands can only create fields in entries, 
not modify them. 

nolog If on, disable logging. 


external If on, make Fields marked as "LocalPub" invisible. 
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Example 


set verbose=off 
200:Done. 


na 


set 

-200:echo:off 
-200:limit:2 
-200:charset:iso-8859-1 
-200:verbose:off 
-200:addonly:off 
-200:nolog:off 
-200:external:on 
200:Done. 


ANNNNNnNNNA 


3.6. login, logout, answer, clear, email, and xlogin 

3.6.1. login 
login [alias] 
The "login" command allows client users to identify themselves to the 
Nameserver. More specifically it identifies a client user with a 
particular entry in the Nameserver and allows them to change fields 
in that entry and possibly other entries. It is also necessary to be 
logged in to the Nameserver to view certain sensitive fields in the 
user’s own entry. 
In order to use the "login" command the client must prompt the user 
for their ph alias and password. The client is then responsible for 


(optionally) encrypting the password and sending it to the server. 
This will be covered in sections 3.6.3 (answer) and 3.6.4 (clear). 


C: login foo 
S: 301:,:P"_YSONUS"SDUQ6&%* ‘ZZ’ ?*#Y ‘A_.Z/A>?@SH>*- 


3.6.2. logout 
logout 


The "logout" command allows a user who is logged in to the Nameserver 
to logout. 


C: logout S: 200:0k. 
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3% 


Be 


Sie 


6. 


6. 


6. 


3. answer 
answer encrypted-response 


In response to the login command, the Nameserver responds with a 
random challenge string. The Nameserver client encrypts the 
challenge with the password supplied by the user, uuencodes the 
result into US-ASCII, and returns the printable result in the 
"answer" command: 


login ppomes 

301:.%S&.D*%67S*1?<.2S@DR: Z@M*) AV—<: 4OM>#R>M*HT 

answer M5K’F:NI (a?M?02+-a9 ‘48RA#ZF=L9) G) /XRS7Q*°0>0@-R7X$WGb *50B] 
200:ppomes:Hi how are you? 


NANA 


The encryption algorithm is based on a three rotor Enigma engine. 
There are known attacks on the security of this approach. 


The answer command is also used to return method-specific responses 
to the xlogin command (section 3.6.6). 


4. clear 

clear cleartext-—password 

The "clear" command can be used instead of the "answer" command to 
complete a login sequence. It’s argument is the user’s cleartext 


password. This command is supplied only to support those clients 
that have not implemented one of the encryption engines used by the 


"answer" command. It’s use is strongly discouraged. 
C: login ppomes 
S: 301:E=@Y&VW*_9YVI;D5. [EBO:B) 9Z#_&X$:2) /eL$VJC87 
C: clear MySecret 
S: 200:ppomes:Hi how are you? 


5. email 
email local-userid 


The "email" command can also be used instead of the "answer" command 
to complete a login sequence. The value of local-userid is the 
user’s login name on the local machine. If all of the following 
conditions are true, then the email command will be accepted by the 
server: 


Hedberg & Pomes Informational [Page 11] 


RFC 2378 The CCSO Nameserver (Ph) Architecture September 1998 


1) The connection to the server originates on port 1023 or less on 
the client. Note: This is a system port. Port 1023 is not 
allocated to this use. 


2) The canonical name of the client’s host matches the right-hand 
side of the email address of the requested alias specified in the 
"login" command. 


3) The "local-userid" matches the left-hand side of the email 
address belonging to the requested alias. 


This is a weak but convenient form of authentication. Depending on 
the information users are allowed to change about themselves and the 
threat environment the server operates in, this method may be 
appropriate. Servers should take care to avoid DNS spoofing. 


3.6.6. xlogin 
xlogin option alias 
Extended login command for GSS, Kerberos v4 and v5, ANSI X9.9 token 
devices (e.g., SNK/4), etc. The option is one of the values returned 


in the Authenticate field of the "siteinfo" command (section 3.2). 
Alias is the user’s alias. 


C: xlogin 16 ppomes 

S: 301:DoKrbLogin started; send Kerberos mutual authenticator. 
C: answer MJa8QO1lcJHYz2IdWyg7uhAnixVqgCZQOBWr64cixYkulktdu.... 
S: 200:ppomes:Hi how are you? 

C: xlogin 4 ppomes 

S: 302:SNK Challenge "024142": 

C: answer 82344338 

S: 200:ppomes:Hi how are you? 


The answer command returns the requested quantity, Kerberos 
authenticator, X9.9 device response, etc. Binary quantities are 
first uuencoded into US-ASCII. 


3.7. add 
add field=value... 


This command is used to add new entries to the database. You must be 
logged in and have full Hero privileges (section 1.4) to use "add". 


C: add name="doe john" id="123456789" alias="j-doe" 
S: 200:0k. 
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3.8. query 
query [field=]value [field=value] . . . [return fieldl [field2]] 


If no field is specified together with a value then the field is 
assumed to be "name" and/or "nickname". When more than one field- 
value specification are given in a query, entries matching all 
specifications are returned (implicit AND). 


It is possible to define which fields should be returned by adding a 
"return" clause. If no return clause is defined the Ph server will 
return a default list of fields. Typical default fields are "alias", 
"name", "title", "email", "phone", "address", "department", "www", 
and "other". A return clause consists of the word "return" followed 
by a list of fields or the word "all". If the word "all" is used 
then all viewable fields will be returned. 


C: query name=doe name=john 

S: 102:There was 1 match to your request. 
Se =20021% alias: j-doe 

S% =2:0 Osis name: doe john 

S: 200:0k. 


3.9. delete 


delete [field=]value... 


This command is used to delete entire entries from the database. You 
must be logged in and have full Hero (section 1.4) privileges to use 
"delete". 


The arguments to the "delete" command are the same as the selection 
part of a "query" command. "Delete" finds all the entries that match 
the argument(s) and deletes them. 


The "delete" command obeys the Nameserver "limit" option, which can 
be used to prevent deletion of more entries than intended. 


C: delete name="doe john" id="123456789" alias="j-doe" 
S: 200:1 entries deleted. 


3.10. change 


change [field=]value [make|force] field="value"... 
This command is used to change one or more fields in one or more 


entries to the values specified. The "change" command consists of 
two clauses, the "change" clause and the "make" or "force" clause. 
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The "change" clause determines which entries will be affected by the 
command. It uses the same arguments as the selection clause of a 
"query" command. The "make" or "force" clause specifies which 
field(s) will be changed and the new value(s) of the specified 
field(s). The "force" clause is only used to make non-encrypted 
changes to fields marked "Encrypt". 


You must be logged in to use "change". 


The "change" command obeys the Nameserver "limit" option, which can 
be used to prevent changing the field contents of more entries than 


intended. 
C: change alias=j-doe force password=NewSecret 
S: 200:1 entry changed. 
C: set limit=500 
S: 200:Done. 
C: change fax="(619) 555-1212" make fax="(760) 555-1212" 
S: 200: 113 entries changed. 


3.11. help 
help [{native|client} [topic ...]] 


Prints help on the Nameserver or on specific clients. If client is 
specified, it should be a valid Nameserver client identifier, such as 
"ph". The client-specific help will first be searched for topic, and 
then the native help will be searched. If topic is omitted, a list 
of all available help texts will be returned. If "native" or client 
are also omitted, a list of clients will be returned. 


C: help native 101 
=—200s- 12101 
-200:1: The Nameserver echo option is set. The text of this response is 


-200:1: the command you just gave, which has not (yet) been executed. 
200:0k. 


3.12. quit/exit/stop 
quit 


Terminates the session with the Nameserver and causes the client to 


exit. 
C: quit 
S: 200:Bye! 
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4. Security 
4.1. Transport Layer 


In the absence of encryption between client and server, all 
Nameserver traffic is unsecure. Kerberos v4, v5, and the GSS-API all 
provide encryption mechanisms, however the Nameserver protocol does 
not support the means to negotiate encryption between client and 
server. This implies that all traffic can be seen by other machines 
having access to the network linking the client and server. 
Furthermore clear-text traffic is subject to modification in transit 
between client and server. Possible ways of augmenting this would be 
to use something like TLS [TLS] or IPSec [IPSEC]. 


4.2. Server Authentication 


Unless one of the mutual authentication mechanisms is used, e.g., 
Kerberos 4/5 or GSS-API, there is no way to prove the identity of a 
server. Further, there is no mechanism to prove a given server is 
authoritative for a set of information. 


4.3. Secure User Authentication 


The Ph protocol allows the negotiation of several authentication 
protocols between client and server, some weak and some strong. It 
does not prohibit the use of cleartext passwords, something which 
should be depreciated, but is useful when dealing with some clients. 


4.4. Privacy and Access Lists 


Directory services like the CCSO white pages server that contain 
information on persons have to consider privacy issues. This paper 
describes one way of partitioning specific attributes from unwanted 
access by designating them visible only to the "local" community, 
visible only to the person connected with the information, or visible 
only to the database administrator. 


Hedberg & Pomes Informational [Page 15] 


RFC 2378 The CCSO Nameserver (Ph) Architecture 


4.5. References 


September 1998 


[GSS-API] Linn, J., "Generic Security Service Application Program 


Interface, Version 2", RFC 2078, 


January 1997. 


[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 
Hashing for Message Authentication", RFC 2104, February 
1997. 

[IPSEC] Atkinson, R., "Security Architecture for the Internet 


Protocol", RFC 1825, August 1995. 


[KRB5] Kohl, J., and C. Neuman, "The Kerberos Network 


Authentication Service (V5)", RFC 1510, 


[TLS] Dierks, T., and C. Allen, "The TLS Protocol, 


Version 1.0", Work in Progress. 


September 1993. 


[MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 
Extensions, (MIME) Part One: Format of Internet Message 


Bodies", RFC 2045, November 1996. 
5. Miscellaneous 
5.1. Authors’ Addresses 


Roland Hedberg 
Umdac 

Umea University 
901 87 Umea 
Sweden 


EMail: Roland.Hedberg@umdac.umu.se 
Paul Pomes 

Qualcomm Inc 

6455 Lusk Blvd 

San Diego, CA 

USA 


EMail: ppomes@qualcomm.com 


Hedberg & Pomes Informational 


[Page 16] 


RFC 2378 


Appendix A 


The CCSO Nameserver 


(Ph) 


Architecture 


September 1998 


Default fields and suggested lengths connected to different object 


types. 


All entries: 
type 

name 
address 
proxy 
password 


type=phone: 
phone 


fax 


type=person: 


Information common to all entries 


64 
256 
128 
32 
32 


Information found in a phonebook 


64 
64 


Information about a human being 


Information about an employee 


alias 32 
forename 64 
surname 64 
group 32 
email 128 
public_key 4096 
nickname 128 
www 256 
acl 128 
type=staff: 

empno 16 
department 64 
supervisor 64 
secretary 64 
office_location 128 
office_address 128 
office_phone 64 
title 64 
pager 64 
hours 128 
type=unit: 

email 128 
www 256 
public_key 4096 
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Result codes 


100 
101 
102 
103 
200 
201 
300 
301 
302 
400 
401 
402 
403 
475 
500 
501 
502 
503 
504 
505 
506 
507 
508 
509 
510 
511 
512 
513 
514 
515 
516 
517 
518 
520 
521 
and 
522 
523 
524 
525 
526 
527 
528 
529 


In progress (general). 

Echo of current command. 

Count of number of matches to query. 

No hostname found for IP address. 

Success (general). 

Database ready, but read-only. 

More information (general). 

Encrypt this string. 

Print this prompt. 

Temporary error (general). 

Internal database error. 

Lock not obtained within timeout period. 
Login would have been OK, but database read-only 
Database unavailable; try later. 

Permanent error (general). 

No matches to query. 

Too many matches to query. 

Not authorized for requested information. 

Not authorized for requested search criteria. 
Not authorized to change requested field. 
Request refused; must be logged in to execute. 
Field does not exist. 

Field is not present in requested entry. 
Alias already in use. 

Not authorized to change this entry. 

Not authorized to add entries. 

Illegal value. 

Unknown option. 

Unknown command. 

No indexed field in query. 

No authorization for request. 

Operation failed because database is read-only. 
To many entries selected by change command. 
CPU usage limit exceeded. 


September 1998 


Change command would have overridden existing field, 


the "addonly" option is on. 

Attempt to view "Encrypted" field. 
Expecting "answer" or "clear". 

Names of help topics may not contain "/". 
Email authentication failed 

Host name address not found in DNS 


Reverse DNS lookup does not match forward DNS lookup 


General Kerberos database error. 
Selected authentication method not available 
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590 Remote queries not allowed. 
598 Command unknown. 

599 Syntax error. 

600 Ambiguous or multiple match 


Hedberg & Pomes Informational [Page 19] 


RFC 2378 


Appendix C 


The 


CCSO Nameserver (Ph) Architecture September 1998 


Description of the client command language using the augmented 
Backus-Naur Form 


(RFC822) . 


response = code [index] [field] text CRLF 
code = [-] LDIG 2DIGIT ":" 

index = number ":" 

field = 1*SPACE attribute ":" 1*SPACE 
text = 1*( CHAR / LWSP-char ) 

command = ph-command CRLF 


ph-command = 
ph-command = 


a-command 


"status" / a-command / oa-command 
/ av-command / answer-command / query-command 
ph-command =/ delete-command / change-command / "help" / quit-command 


("Siteinfo"/"fields"/"id"/"login"/"help"/"email"/ 


"clear") [attribute] 


oa-command 
av-command 
answer-comman 
query-command 
quit-—command 
change-comman 
delete-comman 


selection 


attribute-value 


value 


estring 
attribute 
number 


quoted-string 
quoted-pair 
qtext 

set 

LWSP-char 


LWS 
CRLF 
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("xlogin") number attribute 

("set"/"add"/"make") 1*attribute-value 

("answer") 1*printable 

("query"/"ph") 1*selection ["return" l*attribute] 
"quit" / "exit" / "stop" 

"Change" 1*selection make l1*attribute-value 
"delete" selection 


value / attribute-value 

attribute "=" value 

1*(cstring / quoted-string / set) 

1*( ALPHA / DIGIT / S_SPEC / set / quoted-pair ) 
1*( ALPHA / DIGIT / "_" / "-" ) 


1* (DIGIT) 


<"> 1* (qtext/quoted-pair) <"> 


" \ " CHAR 


1* 


( CHAR / CR / SPEC1 / DELIMIT1 / DELIMIT2 / LWS ) 


‘[’ 1*(ALPHA/DIGIT) ’]’ 


= SPACE / HTAB 


1* 


((CRLF] (LWSP-char) ) 


CR LF 
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S_SPEC 
SPEC1 
SPEC2 
DELIMIT1 
DELIMIT2 
PRINTABLE 
CTL 
ALPHA 
DIGIT 
LDIG 
SPACE 
SEP 

CR 

LF 

HTAB 
CHAR 
OTHER 


"@ " / 
wrew / 
"Aan / 
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= reer Jtr JI 
— win vA Wee / 
= w\u / 
= SPACE / HTAB / LF 
= LARG / meN / wen 
= $d32..%d126 
= $d0..%d31 / 
= $d65..%d90 / 
= $d48..%d57 

= $d49..%d54 

= $d32 

= (CR LF) 
= $d13 

= $d10 

= %d9 

= $d33..%d126 / %d160.. 
Se set / ny" / wow / wom / 
won / nM / wom / "n~n 
"n / wen vi "<" / 
"an / mM / "a / 


wow / win / 


%d127. 
%d97. 


/ LF 


ww 


wpe 
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-3d122 
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" [= / 


m] " 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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